home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001190_dsr@hplb.hpl.hp.com _Wed May 26 14:08:34 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <dsr@hplb.hpl.hp.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA23220; Wed, 26 May 93 14:08:34 MET DST
  4. Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA19389; Wed, 26 May 1993 14:29:56 +0200
  6. Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Wed, 26 May 93 13:22:39 +0100
  7. Received: by manuel.hpl.hp.com
  8.     (16.6/15.6+ISC) id AA02564; Wed, 26 May 93 13:28:11 +0100
  9. From: Dave_Raggett <dsr@hplb.hpl.hp.com>
  10. Message-Id: <9305261228.AA02564@manuel.hpl.hp.com>
  11. Subject: HTRQ and Kerberos
  12. To: sanders@bsdi.com
  13. Date: Wed, 26 May 93 13:28:09 BST
  14. Cc: www-talk@nxoc01.cern.ch
  15. Mailer: Elm [revision: 66.36.1.1]
  16.  
  17. Tony Sanders writes (Sun, 23 May 1993)
  18.  
  19. > What are you browser writers thinking about supporting wrt HTTP/1.0 request
  20. > headers (e.g., see the kerberos proposal below)?  We need to think about
  21. > how to implement the ChargeTo: and Authorization: headers in a generic
  22. > way so the browser can easily support different styles.  I would
  23. > like to see From:, User-Agent:, and Referer: being used (currently
  24. > I've only seen "Accept: text/plain" and "Authorization: user xxx").
  25.  
  26. I am successfully using the Authorization field within Hewlett Packard
  27. for providing restricted access to Web documents:
  28.  
  29. Two formats:
  30.  
  31.     a)  Authorization: user fred:secret
  32.     b)  Authorization: user fred
  33.  
  34. When the browser gets error code 401 (unauthorized) it asks the user
  35. for a username and password. This is then included as (a) in all subsequent
  36. queries to the same server (same protocol, port and host name). By default
  37. the browser always sends the user name as (b) which it obtains from the
  38. environment variable "USER". This avoid the need for users to type
  39. anything if they are known to the server via the .rhosts or /etc/hosts.equiv
  40. mechanism.
  41.  
  42. This approach matches our needs well, and corresponds to the standard level of
  43. security offered with FTP, rlogin and telnet. Its really great to see someone
  44. extending this to support Kerberos!
  45.  
  46. I have also been studying the privacy enhanced mail proposals and the general
  47. field of authentication and encryption based on public key techniques. These
  48. techniques require the setup of registration authorities that permit you to
  49. look up the public key for any person on the system.
  50.  
  51. Such an approach would allow servers to use the registered public key of a
  52. client to check that a request indeed originated from that client.
  53. Furthermore it would allow clients to be certain that a document obtained
  54. from a server is indeed by whom it claims to be and hasn't been altered in
  55. anyway whatsoever.
  56.  
  57. To do this we will need to define authentication formats for both HTRQ
  58. and MIME headers. This needs to be done in concert with other groups in
  59. the Internet. Is anyone interested in picking this up?
  60.  
  61. Regards,
  62.  
  63. Dave Raggett